JBoss.orgCommunity Documentation
Be aware, JBoss Communications SS7 Stack is subject to changes as it is under active development!
The JBoss Communications SS7 Stack is logically divided into two sections. The lower section includes SS7 Level 3 and below. The lower section is influenced by type of SS7 hardware (Level 1) used.
The upper section includes SS7 Level 4 and above. This logical division is widely based on flexibility of JBoss Communications SS7 Stack to allow usage of any SS7 hardware available in the market and yet JBoss Communications SS7 Stack Level 4 and above remains the same.
Further JBoss Communications SS7 Stack provides flexibility to use the Level 2,3 and Level 4 in same JVM and
in same machine where SS7 Hardware (Level 1) is installed. Or its also possible to have Level 1,2,3 to be installed
on separate machine and Level 4 on separate machine. In latter case M3UA
over SCTP
is leveraged for communication between Level 4 and Level 3 and is called JBoss Communications Signaling Gateway.
Bellow diagram shows complete JBoss Communications SS7 Stack in same machine
Bellow diagram shows JBoss Communications Signaling Gateway
If you use JBoss Communications M3UA stack, you have to use JDK 7 to run the stack as well as to compile source code. M3UA leverages Java SCTP which is available only from JDK 7.
Apart from advantages mentioned in
JBoss Communications SS7 Stack consists of following functional blocks:
Linkset
is logical group of links between two Signaling Points.
This term hides MTP
layer, ie. it abstracts whether hardware
MTP
is used or M3UA.
Three type of Linkset
are defined
DahdiLinkset
: As the name suggests, this linkset is for dahdi
based hardware.
dahdi
boards only provides SS7 MTP1 layer and usually depends on external software to provide MTP2/MTP3 support.
Well known dahdi
based SS7 cards are Diguim
and Sangoma
DialogicLinkset
: Linkset for dialogic
based hardware. dialogic
boards
have MTP2 and MTP3 support on board.
M3UALinkset
: M3UA stands for MTP Level 3 (MTP3) User Adaptation Layer as defined by the IETF SIGTRAN working group in RFC 4666.
M3UALinkset
enables the JBoss Communications SS7 Stack Level 4 (e.g. ISUP, SCCP) to run over IP instead of instead of SS7 network
Each type of linkset has coresponding factory. Configuration of linkset factories is exaplained in subsections of Section 3.4, “ Configuring JBoss Communications SS7 Service ”.
Shell
is Command Line Interface (CLI) tool which allows to manage different aspects of JBoss Communications SS7 Stack in interactive manner.
It connects to different instances of JBoss Communications SS7 Stack which manage Linksets
,
SCCP
routing and M3UA
. For detailed information please refer to: Chapter 5, Shell Command Line.
Usually Shell
will be invoked from remote machine(remote to Linksets
and application protocols).
Service is element which is used to manage LinkSets
and protocols like SCCP
.
SS7 service creates instance of JBoss Communications SCCP Stack and bind's it to JNDI name java:/mobicents/ss7/sccp
SS7 Service is JMX based service deployed in JBoss Application Server
SS7 Service hides the details like whether Level 4 and above connects to JBoss Communications Signaling Gateway via M3UA or SS7 Hardware is installed in same machine as Level 4
Diagram below depicts elements which are deployed as part of
SS7 Service
:
Service serves following purposes:
Access points allows user to access lower layer protocols, like SCCP
and interact through such protocols with SS7
network.
Shell Executor
allows Shell
client to connect and issue commands.
Linkset Manager
persists linksets information and manages their lifecycle, ie. it creates, activates them(also after restart).
Configuration of SS7 Service is exaplained in section Section 3.4, “ Configuring JBoss Communications SS7 Service ”
Diagram below depicts how JBoss Communications SS7 Stack is used:
JBoss Communications Signaling Gateway (SG) is a signaling agent that receives/sends Switched Circuit Network (SCN) native signaling at the edge of the IP network. JBoss Communications Signaling Gateway leverages JBoss Communications M3UA Stack explained in Section 2.5.1, “JBoss Communications M3UA Stack” and Linkset explained in Section 2.1, “Linkset”
Diagram below shows the components which are included in JBoss Communications SG. Configuration of SG is explained in Section 3.7, “ Configuring JBoss Communications Signaling Gateway ”
M3UA is client-server protocol supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP. M3UA is defined by the IETF SIGTRAN working group in RFC 4666. JBoss Communications M3UA Stack can be used on Application Server side or can be used on Signaling Gateway side.
JBoss Communications M3UA Stack uses Java SCTP layer which is available from JDK 7 onwards
Diagram below demonstrates the JBoss Communications M3UA Stack used on Application Server (AS) side. The information below explains the basic functionality of the JBoss Communications M3UA Stack when used as an Application Server which will communicate with an External Signaling Gateway
If configured as an AS, does not support configuring conventional SS7 links etc on that same stack. To use M3UA Stack as AS, the Routing Context (RC) must be known. See Section Section 3.4.1, “Configuring Remote Signaling Gateway” for configuring M3UA Stack as AS. The Remote Signaling Gateway Process (RemSGP) object is created under the M3UA Stack.
Diagram below demonstrates the JBoss Communications M3UA Stack used on Signaling Gateway (SG) side. The JBoss Communications Signaling Gateway provides the Nodal Interworking Function (NIF) that allows SS7 Signaling (SCCP/ISUP) to be inter-worked into the M3UA/IP Network as shown in ???
JBoss Communications M3UA Stack used on SG side will share common point code with a set of M3UA Application Server. M3UA stack on SG side can be configured as Loadbalance or Override traffic mode. It doesn't support Broadcast traffic mode. See Section Section 3.7, “ Configuring JBoss Communications Signaling Gateway ” for configuring M3UA Stack as SG. JBoss Communications M3UA Stack used on SG side doesn't support routing key management messages. The Routing Key should be provisioned statically using the management console.